1
2
Prochain
Non.
Le JSON est uniquement des données, et si vous incluez un commentaire, ce sera également des données.
Vous pourriez avoir un élément de données désigné appelé "_comment" (ou quelque chose) qui devrait être ignoré par les applications qui utilisent les données JSON.
Vous feriez probablement mieux d'avoir le commentaire dans les processus qui génèrent / reçoivent le JSON, car ils sont censés savoir à l'avance ce que seront les données JSON, ou du moins leur structure.
Mais si vous décidez de:
{
"_comment": "le texte du commentaire va ici ...",
"glossaire": {
"title": "exemple de glossaire",
"GlossDiv": {
"title": "S",
"GlossList": {
"GlossEntry": {
"ID": "SGML",
"SortAs": "SGML",
"GlossTerm": "Langage de balisage généralisé standard",
"Acronyme": "SGML",
"Abbrev": "ISO 8879: 1986",
"GlossDef": {
"para": "Un langage de méta-balisage, utilisé pour créer des langages de balisage tels que DocBook.",
"GlossSeeAlso": ["GML", "XML"]
},
"GlossSee": "balisage"
}
}
}
}
}
|
Non, les commentaires de la forme //… ou / *… * / ne sont pas autorisés en JSON. Cette réponse est basée sur:
https://www.json.org
RFC 4627:
Le type de média application / json pour la notation d'objets JavaScript (JSON)
RFC 8259 Le format d'échange de données JSON (JavaScript Object Notation) (remplace les RFC 4627, 7158, 7159)
|
Incluez des commentaires si vous le souhaitez; supprimez-les avec un minificateur avant de les analyser ou de les transmettre.
Je viens de publier JSON.minify () qui supprime les commentaires et les espaces d'un bloc de JSON et le rend valide JSON qui peut être analysé. Donc, vous pouvez l'utiliser comme:
JSON.parse (JSON.minify (ma_str));
Quand je l'ai publié, j'ai eu un énorme contrecoup de personnes en désaccord même avec l'idée, alors j'ai décidé d'écrire un article de blog complet sur les raisons pour lesquelles les commentaires ont du sens en JSON. Il comprend ce commentaire notable du créateur de JSON:
Supposons que vous utilisiez JSON pour conserver les fichiers de configuration, que vous souhaitez annoter. Allez-y et insérez tous les commentaires que vous aimez. Puis dirigez-le via JSMin avant de le transmettre à votre analyseur JSON. - Douglas Crockford, 2012
J'espère que cela sera utile à ceux qui ne sont pas d'accord avec la raison pour laquelle JSON.minify () pourrait être utile.
|
Les commentaires ont été supprimés de JSON par conception.
J'ai supprimé les commentaires de JSON car j'ai vu des gens les utiliser pour contenir des directives d'analyse, une pratique qui aurait détruit l'interopérabilité. Je sais que le manque de commentaires rend certaines personnes tristes, mais cela ne devrait pas.
Supposons que vous utilisiez JSON pour conserver les fichiers de configuration, que vous souhaitez annoter. Allez-y et insérez tous les commentaires que vous aimez. Puis dirigez-le via JSMin avant de le transmettre à votre analyseur JSON.
Source: Déclaration publique de Douglas Crockford sur G +
|
JSON ne prend pas en charge les commentaires. Il n'a jamais été non plus destiné à être utilisé pour les fichiers de configuration où des commentaires seraient nécessaires.
Hjson est un format de fichier de configuration pour les humains. Syntaxe détendue, moins d'erreurs, plus de commentaires.
Voir hjson.github.io pour les bibliothèques JavaScript, Java, Python, PHP, Rust, Go, Ruby, C ++ et C #.
|
AVIS DE NON-RESPONSABILITÉ: VOTRE GARANTIE EST NULLE
Comme cela a été souligné, ce hack tire parti de la mise en œuvre de la spécification. Tous les analyseurs JSON ne comprendront pas ce type de JSON. Les analyseurs de streaming en particulier vont s'étouffer.
C'est une curiosité intéressante, mais vous ne devriez vraiment pas l'utiliser pour quoi que ce soit. Voici la réponse originale.
J'ai trouvé un petit hack qui vous permet de placer des commentaires dans un fichier JSON qui n'affectera pas l'analyse, ni ne modifiera les données représentées de quelque manière que ce soit.
Il semble que lors de la déclaration d'un objet littéral, vous pouvez spécifier deux valeurs avec la même clé, et la dernière est prioritaire. Croyez-le ou non, il s'avère que les analyseurs JSON fonctionnent de la même manière. Nous pouvons donc l'utiliser pour créer des commentaires dans le JSON source qui ne seront pas présents dans une représentation d'objet analysée.
({a: 1, a: 2});
// => Objet {a: 2}
Object.keys (JSON.parse ('{"a": 1, "a": 2}')). Length;
// => 1
Si nous appliquons cette technique, votre fichier JSON commenté pourrait ressembler à ceci:
{
"api_host": "Le nom d'hôte de votre serveur API. Vous pouvez également spécifier le port.",
"api_host": "hodorhodor.com",
"retry_interval": "L'intervalle en secondes entre les tentatives d'appels d'API ayant échoué",
"retry_interval": 10,
"auth_token": "Le jeton d'authentification. Il est disponible dans votre tableau de bord développeur sous" Paramètres "",
"auth_token": "5ad0eb93697215bc0d48a7b69aa6fb8b",
"favorite_numbers": "Un tableau contenant mes numéros préférés de tous les temps",
"numéros_ favoris": [19, 13, 53]
}
Le code ci-dessus est un JSON valide. Si vous l'analysez, vous obtiendrez un objet comme celui-ci:
{
"api_host": "hodorhodor.com",
"retry_interval": 10,
"auth_token": "5ad0eb93697215bc0d48a7b69aa6fb8b",
"numéros_ favoris": [19,13,53]
}
Ce qui signifie qu'il n'y a aucune trace des commentaires et qu'ils n'auront pas d'effets secondaires étranges.
Bon piratage!
|
Pensez à utiliser YAML. C'est presque un sur-ensemble de JSON (pratiquement tous les JSON valides sont des YAML valides) et il permet les commentaires.
|
Vous ne pouvez pas. Au moins, c'est mon expérience d'un rapide coup d'œil sur json.org.
JSON a sa syntaxevisualisé sur cette page. Il n'y a aucune note sur les commentaires.
|
Les commentaires ne sont pas une norme officielle, bien que certains analyseurs prennent en charge les commentaires de style C ++. Celui que j'utilise est JsonCpp. Dans les exemples, il y a celui-ci:
// Options de configuration
{
// Codage par défaut pour le texte
"encoding": "UTF-8",
// Plug-ins chargés au démarrage
"plug-ins": [
"python",
"c ++",
"rubis"
],
// Taille du retrait de tabulation
"indent": {"length": 3, "use_space": true}
}
jsonlint ne valide pas cela. Les commentaires sont donc une extension spécifique à l'analyseur et non standard.
Un autre analyseur est JSON5.
Une alternative à JSON TOML.
Une autre alternative est jsonc.
La dernière version de nlohmann / json a un support facultatif pour ignorer les commentaires lors de l'analyse.
|
Vous devriez plutôt écrire un schéma JSON. Le schéma JSON est actuellement un projet de spécification Internet proposé. Outre la documentation, le schéma peut également être utilisé pour valider vos données JSON.
Exemple:
{
"description": "Une personne",
"type": "objet",
"Propriétés":
{
"Nom":
{
"type": "chaîne"
},
"âge":
{
"type": "entier",
"maximum": 125
}
}
}
Vous pouvez fournir de la documentation à l'aide de l'attribut de schéma de description.
|
Si vous utilisez Jackson comme analyseur JSON, voici comment l'activer pour autoriser les commentaires:
ObjectMapper mapper = new ObjectMapper (). Configure (Feature.ALLOW_COMMENTS, true);
Ensuite, vous pouvez avoir des commentaires comme celui-ci:
{
clé: "valeur" // Commentaire
}
Et vous pouvez également avoir des commentaires commençant par # en définissant:
mapper.configure (Feature.ALLOW_YAML_COMMENTS, true);
Mais en général (comme déjà répondu) la spécification ne permet pas les commentaires.
|
Voici ce que j'ai trouvé dans la documentation de Google Firebase qui vous permet de mettre des commentaires en JSON:
{
"//": "Certains navigateurs l'utiliseront pour activer les notifications push.",
"//": "C'est la même chose pour tous les projets, ce n'est pas l'ID de l'expéditeur de votre projet",
"gcm_sender_id": "1234567890"
}
|
NON. JSON supportait les commentaires, mais ils ont été abusés et supprimés de la norme.
Du créateur de JSON:
J'ai supprimé les commentaires de JSON car j'ai vu des gens les utiliser pour contenir des directives d'analyse, une pratique qui aurait détruit l'interopérabilité. Je sais que le manque de commentaires rend certaines personnes tristes, mais cela ne devrait pas. - Douglas Crockford, 2012
Le site officiel JSON est à JSON.org. JSON est défini comme un standard par ECMA International. Il y a toujours un processus de pétition pour faire réviser les normes. Il est peu probable que des annotations soient ajoutées à la norme JSON pour plusieurs raisons.
JSON de par sa conception est une alternative facile à l'ingénierie inverse (analysée par l'homme) à XML. Il est simplifié au point même que les annotations sont inutiles. Ce n'est même pas un langage de balisage. L'objectif est la stabilité et l'interopérabilité.
Quiconque comprend la relation "has-a" de l'orientation de l'objet peut comprendre n'importe quelle structure JSON - c'est le point essentiel. Il s'agit simplement d'un graphe acyclique dirigé (DAG) avec des balises de nœud (paires clé / valeur), qui est une structure de données quasi universelle.
Cette seule annotation requise peut être "// Ce sont des balises DAG". Les noms de clé peuvent être aussi informatifs que nécessaire, permettant une arité sémantique arbitraire.
N'importe quelle plateforme peut analyser JSON avec seulement quelques lignes de code. XML nécessite des bibliothèques OO complexes qui ne sont pas viables sur de nombreuses plates-formes.
Les annotations rendraient simplement JSON moins interopérable. Il n'y a simplement rien d'autre à ajouter, sauf si vous avez vraiment besoin d'un langage de balisage (XML), et ne vous inquiétez pas si vos données persistantes sont facilement analysées.
MAIS comme l'a également observé le créateur de JSON, il y a toujours eu un support du pipeline JS pour les commentaires:
Allez-y et insérez tous les commentaires que vous aimez.
Puis dirigez-le via JSMin avant de le transmettre à votre analyseur JSON. - Douglas Crockford, 2012
|
Si votre fichier texte, qui est une chaîne JSON, va être lu par un programme, à quel point serait-il difficile de supprimer les commentaires de style C ou C ++ avant de l'utiliser?
Réponse: Ce serait une seule ligne. Si vous faites cela, les fichiers JSON pourraient être utilisés comme fichiers de configuration.
|
Si vous utilisez la bibliothèque Newtonsoft.Json avec ASP.NET pour lire / désérialiser, vous pouvez utiliser des commentaires dans le contenu JSON:
// "nom": "chaîne"
// "id": int
ou
/* C'est un
exemple de commentaire * /
PS: les commentaires sur une seule ligne ne sont pris en charge qu'avec 6+ versions de Newtonsoft Json.
Remarque supplémentaire pour les personnes qui ne peuvent pas penser hors de la boîte: j'utilise le format JSON pour les paramètres de base dans une application Web ASP.NET que j'ai créée. J'ai lu le fichier, je le convertis en objet de configuration avec la bibliothèque Newtonsoft et je l'utilise si nécessaire.
Je préfère écrire des commentaires sur chaque paramètre individuel dans le fichier JSON lui-même, et je ne me soucie vraiment pas de l'intégrité du format JSON tant que la bibliothèque que j'utilise est OK.
Je pense que c'est une manière «plus facile à utiliser / comprendre» que de créer un fichier séparé «settings.README» et d'expliquer les paramètres qu'il contient.
Si vous rencontrez un problème avec ce type d'utilisation; désolé, le génie est hors de la lampe. Les gens trouveraient d'autres usages pourFormat JSON, et vous ne pouvez rien y faire.
|
L'idée derrière JSON est de fournir un échange de données simple entre les applications. Ceux-ci sont généralement basés sur le Web et le langage est JavaScript.
Cela ne permet pas vraiment les commentaires en tant que tels, cependant, passer un commentaire comme l'une des paires nom / valeur dans les données fonctionnerait certainement, bien que ces données devraient évidemment être ignorées ou traitées spécifiquement par le code d'analyse.
Cela dit, l'intention n'est pas que le fichier JSON contienne des commentaires au sens traditionnel du terme. Cela ne devrait être que les données.
Consultez le site Web JSON pour plus de détails.
|
JSON ne prend pas en charge les commentaires de manière native, mais vous pouvez créer votre propre décodeur ou au moins un préprocesseur pour supprimer les commentaires, c'est parfaitement bien (tant que vous ignorez simplement les commentaires et ne les utilisez pas pour guider votre application doit traiter les données JSON ).
JSON n'a pas de commentaires. Un encodeur JSON NE DOIT PAS produire de commentaires.
Un décodeur JSON PEUT accepter et ignorer les commentaires.
Les commentaires ne doivent jamais être utilisés pour transmettre quelque chose de significatif. C'est
à quoi sert JSON.
Cf: Douglas Crockford, auteur de la spécification JSON.
|
Je rencontre juste cela pour les fichiers de configuration. Je ne veux pas utiliser le format XML (verbeux, graphique, moche, difficile à lire), ni le format «ini» (pas de hiérarchie, pas de véritable standard, etc.) ou le format Java «Propriétés» (comme .ini).
JSON peut faire tout ce qu'ils peuvent, mais il est beaucoup moins verbeux et plus lisible par l'homme - et les analyseurs sont faciles et omniprésents dans de nombreuses langues. C'est juste un arbre de données. Mais les commentaires hors bande sont souvent une nécessité pour documenter les configurations «par défaut» et autres. Les configurations ne doivent jamais être des "documents complets", mais des arbres de données sauvegardées qui peuvent être lisibles par l'homme en cas de besoin.
Je suppose que l'on pourrait utiliser "#": "comment", pour "valide" JSON.
|
Cela dépend de votre bibliothèque JSON. Json.NET prend en charge les commentaires de style JavaScript, / * commment * /.
Voir une autre question Stack Overflow.
|
JSON a beaucoup de sens pour les fichiers de configuration et autres utilisations locales car il est omniprésent et parce qu'il est beaucoup plus simple que XML.
Si les gens ont de bonnes raisons de ne pas avoir de commentaires en JSON lors de la communication de données (valides ou non), alors JSON pourrait être divisé en deux:
JSON-COM: JSON sur le câble ou règles qui s'appliquent lors de la communication de données JSON.
JSON-DOC: document JSON, ou JSON dans des fichiers ou localement. Règles qui définissent un document JSON valide.
JSON-DOC autorisera les commentaires, et d'autres différences mineures peuvent exister, telles que la gestion des espaces. Les analyseurs peuvent facilement passer d'une spécification à une autre.
En ce qui concerne la remarque de Douglas Crockford sur ces questions (référencée par @Artur Czajka)
Supposons que vous utilisiez JSON pour conserver les fichiers de configuration, que vous souhaitez annoter. Allez-y et insérez tous les commentaires que vous aimez. Puis dirigez-le via JSMin avant de le transmettre à votre analyseur JSON.
Nous parlons d'un problème de fichier de configuration générique (cross language / platform), et il répond avec un utilitaire spécifique à JS!
Bien sûr, un minify spécifique JSON peut être implémenté dans n'importe quelle langue,
mais standardisez cela pour qu'il devienne omniprésent dans les analyseurs dans toutes les langues et plates-formes afin que les gens cessent de perdre leur temps à manquer de cette fonctionnalité parce qu'ils ont de bons cas d'utilisation, recherchent le problème dans les forums en ligne et amènent les gens à leur dire que c'est une mauvaise idée ou en suggérant qu'il est facile d'implémenter la suppression des commentaires des fichiers texte.
L'autre problème est l'interopérabilité. Supposons que vous ayez une bibliothèque ou une API ou tout type de sous-système auquel sont associés des fichiers de configuration ou de données. Et ce sous-système est
accessible à partir de différentes langues. Alors tu vas dire aux gens: au fait
n'oubliez pas de supprimer les commentaires des fichiers JSON avant de les transmettre à l'analyseur!
|
Si vous utilisez JSON5, vous pouvez inclure des commentaires.
JSON5 est une extension proposée à JSON qui vise à faciliter l'écriture et la maintenance manuelle par les humains. Pour ce faire, il ajoute des fonctionnalités de syntaxe minimales directement à partir d'ECMAScript 5.
|
La boîte à outils JavaScript Dojo Toolkit (au moins à partir de la version 1.4), vous permet d'inclure des commentaires dans votre JSON. Les commentaires peuvent être au format / * * /. Dojo Toolkit utilise le JSON via l'appel dojo.xhrGet ().
D'autres boîtes à outils JavaScript peuvent fonctionner de la même manière.
Cela peut être utile lors de l'expérimentation d'autres structures de données (ou même de listes de données) avant de choisir une option finale.
|
JSON n'est pas un protocole encadré. C'est un format libre de langue. Le format d'un commentaire n'est donc pas défini pour JSON.
Comme beaucoup de gens l'ont suggéré, il existe quelques astuces, par exemple, des clés en double ou un _comment de clé spécifique que vous pouvez utiliser. C'est à vous.
|
Vous pouvez avoir des commentaires en JSONP, mais pas en JSON pur. Je viens de passer une heure à essayer de faire fonctionner mon programme avec cet exemple de Highcharts: http://www.highcharts.com/samples/data/jsonp.php?filename=aapl-c.json&callback=?
Si vous suivez le lien, vous verrez
? (/ * AAPLdonnées OHLC historiques de l'API Google Finance * /
[
/ * Mai 2006 * /
[1147651200000,67.79],
[1147737600000,64,98],
...
[1368057600000,456,77],
[1368144000000,452,97]
]);
Comme j'avais un fichier similaire dans mon dossier local, il n'y avait aucun problème avec la politique de même origine, j'ai donc décidé d'utiliser du JSON pur ... et, bien sûr, $ .getJSON échouait silencieusement à cause des commentaires.
Finalement, je viens d'envoyer une requête HTTP manuelle à l'adresse ci-dessus et j'ai réalisé que le type de contenu était du texte / javascript puisque, eh bien, JSONP renvoie du JavaScript pur. Dans ce cas, les commentaires sont autorisés. Mais mon application a renvoyé une application de type contenu / json, j'ai donc dû supprimer les commentaires.
|
C'est une question "pouvez-vous". Et voici une réponse «oui».
Non, vous ne devez pas utiliser de membres d'objet duplicatifs pour insérer des données de canal secondaire dans un encodage JSON. (Voir «Les noms dans un objet DEVRAIENT être uniques» dans la RFC).
Et oui, vous pouvez insérer des commentaires autour du JSON, que vous pouvez analyser.
Mais si vous voulez un moyen d'insérer et d'extraire des données arbitraires de canal secondaire dans un JSON valide, voici une réponse. Nous profitons de la représentation non unique des données dans un encodage JSON. Ceci est autorisé * dans la section deux de la RFC sous "l'espace blanc est autorisé avant ou après l'un des six caractères structurels".
* La RFC indique uniquement que "les espaces blancs sont autorisés avant ou après l'un des six caractères structurels", sans mentionner explicitement les chaînes, les nombres, "false", "true" et "null". Cette omission est ignorée dans TOUTES les implémentations.
Tout d'abord, canonisez votre JSON en le minifiant:
$ jsonMin = json_encode (json_decode ($ json));
Puis encodez votre commentaire en binaire:
$ hex = unpack ('H *', $ commentaire);
$ commentBinary = base_convert ($ hex [1], 16, 2);
Puis steg votre binaire:
$ steg = str_replace ('0', '', $ commentBinary);
$ steg = str_replace ('1', "\ t", $ steg);
Voici votre sortie:
$ jsonWithComment = $ steg. $ jsonMin;
|
Avertissement: C'est idiot
Il existe en fait un moyen d'ajouter des commentaires et de rester dans les spécifications (aucun analyseur supplémentaire n'est nécessaire). Cela n'entraînera pas de commentaires lisibles par l'homme sans aucune sorte d'analyse.
Vous pourriez abuser de ce qui suit:
Un espace blanc insignifiant est autorisé avant ou après tout jeton.
L'espace blanc est une séquence d'un ou plusieurs des codes suivants
points: tabulation de caractères (U + 0009), saut de ligne (U + 000A), chariot
return (U + 000D) et espace (U + 0020).
De manière piratée, vous pouvez en abuser pour ajouter un commentaire. Par exemple: commencez et terminez votre commentaire par un onglet. Encodez le commentaire en base3 et utilisez les autres caractères d'espacement pour les représenter. Par exemple.
010212 010202 011000 011000 011010 001012 010122 010121 011021 010202 001012 011022 010212 011020 010202 010202
(bonjour la base trois en ASCII) Mais au lieu de 0, utilisez l'espace, pour 1 utilisez le saut de ligne et pour 2 utilisez le retour chariot.
Cela vous laissera juste avec beaucoup d'espaces illisibles (à moins que vous ne fassiez un plugin IDE pour l'encoder / le décoder à la volée).
Je n'ai même jamais essayé cela, pour des raisons évidentes et vous ne devriez pas non plus.
|
JSON n'autorise pas les commentaires en soi. Le raisonnement est complètement insensé, car vous pouvez utiliser JSON lui-même pour créer des commentaires, ce qui évite complètement le raisonnement et charge l'espace de données de l'analyseur sans aucune bonne raison du tout pour exactement le même résultat et les problèmes potentiels, tels qu'ils sont: un JSON fichier avec commentaires.
Si vous essayez de mettre des commentaires (en utilisant // ou / * * / ou # par exemple), certains analyseurs échoueront car ce n'est strictement pas
dans la spécification JSON. Vous ne devriez donc jamais faire ça.
Ici, par exemple, où mon système de manipulation d'image a enregistré des notations d'image et quelques informations formatées (commentaires) de base les concernant (en bas):
{
"Notations": [
{
"anchorX": 333,
"ancre": 265,
"areaMode": "Ellipse",
"extendX": 356,
"étendueY": 294,
"opacité": 0,5,
"text": "Zone elliptique en haut",
"textX": 333,
"textY": 265,
"title": "Notation 1"
},
{
"anchorX": 87,
"ancre": 385,
"areaMode": "Rectangle",
"extendX": 109,
"étendueY": 412,
"opacité": 0,5,
"text": "Rect area \ non bottom",
"textX": 98,
"textY": 385,
"title": "Notation 2"
},
{
"anchorX": 69,
"ancre": 104,
"areaMode": "Polygone",
"extendX": 102,
"étendueY": 136,
"opacité": 0,5,
"pointList": [
{
"i": 0,
"x": 83,
"y": 104
},
{
"i": 1,
"x": 69,
"y": 136
},
{
"i": 2,
"x": 102,
"y": 132
},
{
"i": 3,
"x": 83,
"y": 104
}
],
"text": "Polygone simple",
"textX": 85,
"textY": 104,
"title": "Notation 3"
}
],
"imageXW": 512,
"imageYW": 512,
"imageName": "lena_std.ato",
"tinyDocs": {
"c01": "Données de notation d'image JSON:",
"c02": "-------------------------",
"c03": "",
"c04": "Ces données contiennent des notations d'image et la zone associée",
"c05": "informations de sélection qui fournissent un moyen pour un",
"c06": "galerie d'images pour afficher les notations avec elliptique,",
"c07": "indications de zone rectangulaire, polygonale ou à main levée",
"c08": "sur une image affichée à un visiteur de la galerie.",
"c09": "",
"c10": "Les positions X et Y sont toutes dans l'imageespace. L'image",
"c11": "la résolution est donnée comme imageXW et imageYW, qui",
"c12": "vous utilisez pour mettre à l'échelle les zones de notation à leur convenance",
"c13": "emplacements et tailles d'affichage de l'image,",
"c14": "quelle que soit l'échelle.",
"c15": "",
"c16": "Pour les Ellipses, l'ancre est le centre de l'ellipse,",
"c17": "et les étendues sont respectivement les rayons X et Y.",
"c18": "",
"c19": "Pour les rectangles, l'ancre est en haut à gauche et le",
"c20": "les étendues sont en bas à droite.",
"c21": "",
"c22": "Pour les modes Zone à main levée et Polygone, le pointList",
"c23": "contient une série de points XY numérotés. Si la zone",
"c24": "est fermé, le dernier point sera le même que le",
"c25": "d'abord, il ne vous reste plus qu'à dessiner",
"c26": "lignes entre les points de la liste. Ancre et étendue",
"c27": "sont définis en haut à gauche et en bas à droite de l'indication",
"c28": "région, et peut être utilisé comme un rectangle simpliste",
"c29": "détecter la position de survol de la souris sur ces types",
"c30": "des zones.",
"c31": "",
"c32": "Les positions textx et texty fournissent un positionnement de base",
"c33": "informations pour vous aider à localiser les informations textuelles",
"c34": "dans un emplacement raisonnable associé à la zone",
"c35": "indication.",
"c36": "",
"c37": "L'opacité est une valeur comprise entre 0 et 1, où 0,5 représente",
"c38": "un fond opaque à 50% et 1.0 représente un fond totalement opaque",
"c39": "toile de fond. Il est recommandé de dessiner des régions",
"c40": "uniquement si l'utilisateur place le pointeur sur l'image,",
"c41": "et que le texte associé aux régions soit dessiné",
"c42": "uniquement si l'utilisateur place le pointeur sur l'indication",
"c43": "région".
}
}
|
Nous utilisons strip-json-comments pour notre projet. Il prend en charge quelque chose comme:
/ *
* La description
* /
{
// arcs en ciel
"licorne": / * ❤ * / "gâteau"
}
Simplement npm install --save strip-json-comments pour l'installer et l'utiliser comme:
var strip_json_comments = require ('strip-json-comments')
var json = '{/ * arcs-en-ciel * / "licorne": "gâteau"}';
JSON.parse (strip_json_comments (json));
// => {licorne: 'gâteau'}
|
Dans mon cas, je dois utiliser des commentaires à des fins de débogage juste avant la sortie de la structure JSON. J'ai donc décidé d'utiliser les informations de débogage dans l'en-tête HTTP, pour éviter de casser le client:
header ("My-Json-Comment: Oui, je sais que c'est une solution de contournement ;-)");
|
Pour couper un élément JSON en parties, j'ajoute des lignes de "commentaire factice":
{
"#############################" : "Partie 1",
"data1": "value1",
"data2": "value2",
"#############################" : "Partie 2",
"data4": "value3",
"data3": "value4"
}
|
1
2
Prochain
Question très active. Gagnez 10 points de réputation pour répondre à cette question. L'exigence de réputation permet de protéger cette question contre les spams et les activités sans réponse.
Ce n'est pas la réponse que vous recherchez? Parcourez les autres questions marquées des commentaires json ou posez votre propre question.